Method, system, and computer program product for linking customer information

ABSTRACT

In a business where a database tracks customers and manages customer accounts, a method and system correctly link accounts with customers. The method entails reading customer information for a first customer and for a second customer, and then utilizing personal identification information obtained from other sources to determine if the first customer is the same as the second customer. If the first customer and the second customer are the same person, the first customer and the second customer are identified as being the same unique person. Accounts associated with the two customers are identified as belonging to the same unique person. Viewed another way, the method and system of the present invention takes an existing database of personal identification information, and cross-references that database against other sources of personal identification information to identify persons who appear to be separate persons, but who are actually one and the same individual.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of claims priority to and the benefitof, U.S. Ser. No. 11/529,604 filed Sep. 29, 2006 and entitled “METHOD,SYSTEM, AND COMPUTER. PROGRAM PRODUCT FOR LINKING CUSTOMER INFORMATION.”The '604 application claims priority to, and the benefit of U.S.Provisional patent application Ser. No. 60/722,038, filed Sep. 30, 2005.Both of which are hereby incorporated by reference in their entirety.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention generally relates to managing customer informationwithin a database, and more particularly to ensuring that most orsubstantially all customer accounts are correctly linked to appropriatecustomer information within a customer database. The present inventionfurther relates to ensuring that most or substantially all uniquecustomers are not erroneously identified as two or more customers, butare instead correctly identified as being a single unique customer.

Related Art

Customers often have more than one account established through abusiness, especially with a service-oriented business such as afinancial services company or an insurance business. In the case of thefinancial services industry, for example, a single customer may have anycombination of a personal bank account, a mortgage, a line of credit(such as a home equity line of credit), a personal credit card, abusiness credit card, a rewards account, and one or more investmentaccounts with a single financial institution. In the insurance business,a single customer may have any combination of health insurance, autoinsurance, home owners insurance, and other kinds of insuranceprotection as well. Even with non-service businesses, a single customermay have multiple accounts. For example, a single customer may have oneaccount with a computer supply company for home purchases and anotheraccount with the same company for small business purchases.

It is important for a company to recognize that all of the customer'saccounts belong to a single customer and to link those accounts, inorder to appropriately market to the customer without overloading thecustomer. In addition, each customer may have preferences with respectto their privacy, and with respect to a variety of matters related tothe management of their accounts. It is important for effectivebusiness-customer relations that these customer preferences be respectedin relation to all accounts associated with the customer.

Further, ensuring that all accounts for a given customer are, in fact,accurately associated with that customer is vital for businesses whichoffer decision-support to their customers, as is the case, to name justone example, with a financial service business that provides portfolioand asset management. The correct linking of accounts with a customercan improve the accuracy of the financial company's estimate of thefinancial status of the customer,

In practice, accurately linking accounts with a single customer provesto be a non-trivial undertaking. It is possible to associate one or moreaccounts with a single customer based on unique customer identifyinginformation, such as the customer name, social security number, date ofbirth, address, and other distinctive or unique identifiers. However,the association process is fallible. For example, sometimes someinformation is not collected; if a customer's business is applying for acredit card, for example, then a tax ID number may be collected ratherthan the customer's social security number,

It is also possible that variations may creep into the way a customer'sname is recorded, or the way the address is recorded, or simply thaterrors are made during the process of collecting customer identifyingdata. People change addresses over time, or change their name, which canthwart efforts to make account associations based on the name, address,or other time-variant identification data. There are other factors aswell which can contribute to a failure to correctly identify that two ormore distinct accounts are actually associated with a single customer.

Still another factor which makes it difficult to effectively recognizewhich accounts are, in fact, associated with a single customer is thesize of many businesses. A large service business, such as a largefinancial institution, may have multiple business units. Often, thesebusiness units do not efficiently or effectively share information,since in some cases data processing may be distributed over multiplecomputer systems and software systems. As a result customer informationcan be fragmented over these multiple data processing systems and theirassociated databases.

It is also possible that accounts can be incorrectly linked, i.e., thataccounts which actually belong to two separate customers becomeassociated, within the business database, with a single customer. Thiscan happen through various errors in data association or the dataassociation process, and can also occur as a result of deliberate fraudby third-parties, e.g., identity theft.

Still, it is essential that the linking of customer accounts beaccurate, so that accounts from two different customers are notincorrectly linked and/or that accounts belonging to the same customerare not left unlinked.

Given the foregoing, what is needed is a method, system, and computerprogram product for linking customer information. In particular, what isneeded is a method, system, and computer program product that provides asubstantially complete and accurate view of product relationships forprospects and customers across all lines of business, products andservices, no matter how large the company or business may be, and nomatter how diverse the product lines or service lines. The method,system, and computer program product should ensure that there is noredundancy in customer identification, ie., that one single, uniquecustomer is not erroneously viewed within the company database system orsystems as being multiple customers. What is further needed is a method,system, and computer program product to ensure that all customeraccounts are correctly linked to the appropriate customers who own theaccounts, without any erroneous linkages.

BRIEF SUMMARY OF THE INVENTION

The present invention meets the above-identified needs by providing amethod, system, and computer program product for linking customerinformation. This method is referred to as the customer linking andidentification capability (CLIC) method, or as the “CLIC method” inbrief.

in one embodiment of the invention, the CLIC method comprises collectinginternal customer account data into a consolidated database, and thensearching one or more external databases for personal identificationinformation which is related to customer account data, wherein theexternal databases are not part of the company's in-house repository ofcustomer data. An analysis is performed to compare internal customeraccount data with the externally obtained personal identificationinformation so as to determine which accounts, previously listed asbelonging to separate customers, actually belong to the same customer.Linkages are then created between all accounts belonging to a single,unique customer.

Further embodiments, features, and advantages of the present invention,as well as the structure and operation of the various embodiments of thepresent invention, are described in detail below with reference to theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The features and advantages of the present invention will become moreapparent from the detailed description set forth below when taken inconjunction with the drawings in which like reference numbers indicateidentical or functionally similar elements. Additionally, the left-mostdigit or digits of a reference number identifies the drawing in whichthe reference number first appears.

FIG. 1 is a system diagram of an exemplary business intranet environmentand external network and database environment in which the presentinvention, in an embodiment, would be implemented.

FIG. 2A is a flowchart illustrating a customer linking andidentification capability (CLIC) process according to one embodiment ofthe present invention.

FIG. 2B is a flowchart illustrating a CLIC process according to anenhanced version of the embodiment of the present invention illustratedin FIG. 2A, showing additional steps which may be advantageous toperform.

FIG. 3 is a system diagram illustrating possible sources of internalcustomer account data at a representative business, and fartherillustrating the consolidation and filtering of that data into theconsolidated database.

FIG. 4 is an example of representative customer account data beingimported into the consolidated database.

FIG. 5A is a system diagram illustrating possible sources of externalpersonal identification information, and further illustrating theimporting of that data into the centralized repository for external datavia a matching and filtering process.

FIG. 5B is a block diagram illustrating representative criteria that maybe used in an embodiment of the invention to determine which externaldata corresponds to customer data in the internal consolidated database,and therefore which external data should be imported into thecentralized repository for external data.

FIG. 6 is an example of representative external personal identificationinformation which is matched and filtered for import into thecentralized repository for external data.

FIG. 7 is a flow chart of a method by which linkage recommendations aremade, and linkages established, between customers and customer accountsin one embodiment of the present invention.

FIG. 8 is a block diagram showing both the flow of data and the dataprocessing entailed in making an initial linkage recommendation in anembodiment of the present invention.

FIG. 9A is an example of how the initial rules may be applied to analyzeexternal personal identification data in relation to a customer listedin the consolidated database.

FIG. 9B is an example of how the initial rules may be applied to linktwo customer accounts.

FIG. 10A is a first example of a secondary linking rule, and theapplication of the rule to a customer linkage.

FIG. 10B is a second example of a secondary linking rule, and theapplication of the rule to a customer linkage.

FIG. 11A is a flowchart showing the detailed steps of the linkagerecommendations involved in steps 704 and 710.

FIG. 11B is a flowchart showing the detailed steps for linking customerrecords, formerly treated as separate customers, so that they are oneunique customer, and also linking the appropriate customer accounts tothe one unique customer.

FIG. 12 is an alternative representation of a customer linking andidentification capability method.

FIG. 13 illustrates two examples of corrections required due to overlinkerrors or underlink errors.

FIG. 14 illustrates the hierarchy of linking rules in a CLIC processwhich employs multiple stages of rules processing.

FIG. 15 is a block diagram of an exemplary computer system useful forimplementing the present invention.

DETAILED DESCRIPTION OF THE INVENTION I. Introduction

The present invention is directed to a method, system, and computerprogram product for linking customer accounts with non-redundant clientidentifications, that is, for linking customer accounts with uniqueclient identifications within a business or other organizationaldatabase. It should be understood that while the method, system, andcomputer program product are described here in the context of businessenterprises, business activities, and customer and account databasesimplemented in a business context, the method, system, and computerprogram product could as well be implemented and applied in othercontexts as well.

For example, the method, system, and computer program product describedherein could be used to link records of a non-commercial nature whichare related to a common, unique person described in a databaseimplemented in a non-commercial and non-business context. Additionally,the method, system, and computer program product described herein couldbe used to identify as one unique person a set of data records,previously identified as belonging to separate persons, in anon-business or non-commercial database or set of databases.

For example, the method described in this invention could haveapplications in law enforcement in identifying persons who are listed indifferent states or different municipalities as being different personsbut are in fact the same person, or it could be employed to identifyindividuals who have attended different schools or have been employed invarious jobs who are in fact the same persons.

The present invention is referred to variously as the “method, system,and computer program product for linking customer information”, the“customer linking and identification capability method”, the “customerlinking and identification capability system”, the “customer linking andidentification capability process”, the “customer linking andidentification capability computer program product”, the “CLIC method”,the “CLC process”, the “CLIC computer program product”, or the “CLICsystem”, and these terms are used interchangeably throughout thisdocument.

The present invention is now described in more detail herein in terms ofan exemplary business context, and typically in the context of afinancial business. This is for convenience only and is not intended tolimit the application of the present invention. In fact, after readingthe following description, it will be apparent to one skilled in therelevant art(s) how to implement the following invention in alternativeembodiments, as indicated above. Thus, the description provided below isfor purposes of illustration and explanation only, and should not beconstrued as limiting the scope of the invention. Rather, the scope ofthe invention is determined by the appended claims.

The terms “consumer”, “customer”, “client”, “person”, “individual”,“prospect”, and/or the plural form of these terms are usedinterchangeably throughout herein to refer to those persons or entitiescapable of accessing, using, being affected by, being listed in the oneor more databases of purchasing the products of being clients of seekingthe products and/or services of, being offered products and/or servicesof and/or subscribing to or benefiting from the products and/or servicesof the representative business unit, units, organization, ororganizations which would implement and apply the method, system, andcomputer program product tool that the present invention provides forlinking customer information.

Furthermore, the terms “business”, “merchant”, “organization”, and/or“enterprise” may be used interchangeably with each other and shall meanany person, entity, distributor system, software and/or hardware that isa provider, broker and/or any other entity in the distribution chain ofgoods or services. For example, a merchant may be a grocery store, aretail store, a travel agency, a service provider, an on-line merchant,a financial institution or service provider, or the like. A business ororganization as understood herein may include not only for-profitbusinesses, but also non-profit or not-for-profit organizations such asschools, and may even be construed to encompass governmental orsemi-governmental agencies, including but not limited to the PostOffice, law enforcement agencies, etc.

An “account” commonly refers to a set or collection of data whichindicates transactions between a customer and a business which aretypically bundled together under the name of a service of some kind,and/or a status or statuses of services which a business may provide toa consumer, and/or a set of one or more legal or financial obligationson the part of a business towards the consumer, and/or a set of one ormore legal or financial obligations on the part of a consumer towards abusiness. For example, a loan account may record a customers creditline, as well as specific transactions wherein the customer has borrowedmoney against the loan account or paid back principle or interest on theaccount.

However, for purposes of this document, an “account” may also beunderstood to refer more broadly to any kind of collection of data whicha business or organization may maintain in relation to a customer orother person associated with the business or organization. An example ofan account, understood in this broader sense, might be a student'stranscript of grades at an educational institutional. (The student maywell have a second or third account at the same institution, related totuition payments, financial aide, etc.)

An “account number”, as used herein, and as sometimes also referred tosimply as an “account”, may include any device, code, number, letter,symbol, digital certificate, smart chip, digital signal, analog signal,biometric or other identifier/indicia suitably configured to allow aconsumer to access, interact with or communicate with a financialtransaction system or other transaction system. The account number mayoptionally be located on or associated with any financial transactioninstrument (e.g., rewards, charge, credit, debit, prepaid, telephone,embossed, smart, magnetic stripe, bar code, transponder or radiofrequency card).

A customer account number may he, for example, a sixteen-digit creditcard number. Each credit card issuer has its own numbering system, suchas the fifteen-digit numbering system used by American Express Companyof New York, N.Y. A merchant account number may be, for example, anynumber or alpha-numeric characters that identifies a particular merchantfor purposes of card acceptance, account reconciliation, reporting andthe like.

A “generation code”, sometimes called a “suffix”, is a suffix to a name,which may be a full word such as “Senior” or “Junior” or similar, or anabbreviated appellation such as “Sr.”, or “Jr.” or similar, or may be anumeric designation such as “the Second”, “the Third”, “2^(nd)”, “3^(rd)”, or similar, or may be a numeric designation such as “theSecond”, “the Third”, or similar, which indicates lineage within afamily, and is generally considered to be part of a person's full name.

II. Overview

Preexisting customer data from one or more accounts held with a businessare input into a consolidated database. One or more external database(s)are searched for personal data which, based on matching and filtercriteria, are candidate matches to the preexisting customer data in theconsolidated database. The external candidate match data is consolidatedinto a centralized repository. The external candidate match data, nowstored in the centralized repository, and the preexisting customer dataare analyzed for matches according to a set of linking rules; theanalysis process may entail a single pass through a single set oflinking rules, or may entail two or more passes through different setsof linking rules, resulting in progressively more accurate matches.

A “match” indicates that a candidate from an external database is likelyto be the same individual as an individual already identified in theconsolidated database. Based on the matches found, linkagerecommendations are made. Each recommendation suggests that a link bemade between multiple accounts, sometimes for accounts previouslyassociated with separate customers, so that the accounts will becomeassociated with a single customer. Each such recommendation alsosuggests that several customers, previously considered to be separatecustomers, should be consolidated into one unique customer.

In a single-pass process, the recommendations are immediatelyimplemented as linkages.

In a two-or-more pass process, preliminary linkage recommendations arethen analyzed and validated according to secondary linking rules,possibly tertiary linking rules, and possibly additional sets of linkingrules, resulting in the links finally being established in theconsolidated database.

The actual linkages may be established through various means, in oneembodiment of the present invention, a persistent ID, unique to eachcustomer, is used to associate all accounts for a single customer.Finally, when triggered by events such as customer requests orindications of errors in the database (such as indications of identitytheft), manual linkages are made to correct for overlink or underlinkerrors.

An advantage of the present invention is that by importing externallyobtained personal identification information, deficiencies (e.g.,omissions and/or errors) in the existing in-house data are compensatedfor. As a result of the additional, externally obtained personalidentification information, it is possible to recognize linkages amonginternal customer records in cases where existing internal customer datawould be insufficient to establish those linkages, no matter howsophisticated might be the data processing algorithm employed to analyzethe internal data alone.

Another advantage of the present invention is that it optionally employsa multistage analysis process to compare external personalidentification data with internal data. As a result of this optionalmultistage analysis process, it is possible to create a robust customerlinking process which employs both “off the shelf” or third-party dataanalysis/data matching software and algorithms in one stage of theprocess, and also custom-designed data analysis/data, matching softwareand algorithms in another stage. The custom-designed algorithms may betuned or optimized for the particular database requirements and customerlinking requirements of a particular business. The optional multistageprocessing also enables manual or automated error-checking and linkvalidation at multiple stages in the customer linking process.

Another advantage of the present invention is that, by reducing oreliminating redundant customer identifications, and correctly linkingmultiple customer accounts with unique customers, the invention improvesthe ability of a business to offer integrated services and support to acustomer by recognizing all aspects of the business in which the uniquecustomer participates or subscribes.

III. System

FIG. 1 is a system diagram of an exemplary business data processingenvironment 100 in which the present invention, a customer linking andidentification capability (CLIC) method, in an embodiment, would beimplemented.

System 100 includes a business or organizational intranet 114, which inturn has a computer or server 102. Computer 102 is connected to aback-end consolidated database 112 and also to a centralized repositoryfor external data 108. Computer 102 is also connected to one or moreother data sources which represent sources of internal customer accountdata 104. This internal customer account data may be related to creditcard accounts, banking accounts, investment accounts, or any number ofother kinds of financial or commercial accounts which are owned bycustomers of the business. The account data includes both identificationinformation about the accounts themselves, transaction related data suchas the financial status of the account, and also information about thecustomer or customers who own the account.

The consolidated database 112 is also referred to as the customerlinking and identification capability database 112 or the CLIC database112, a reference to the CLIC method of the current invention. The terms“consolidated database” and “CLIC database” will be used interchangeablythroughout the rest of this document.

In addition to being connected to the internal customer account data104, which may be stored on one or possibly more servers throughout thebusiness institution which is implementing the CLIC method, and/orthroughout affiliates of the business institution which is implementingthe CLIC method, computer 102 is also connected to a source ofinformation about personal identification information. In the embodimentillustrated in FIG. 1, the personal identification information isavailable on one or more external database(s) 106 which can be accessedthrough a network 110. In a typical embodiment the external database(s)106 are external to the financial or other business institution, andnetwork 110 represents access through the Internet or through othernetworks.

Computer 102 will obtain personal identification information fromexternal database(s) 106 through network 110, and will store thepersonal identification information in centralized repository forexternal data 108. Centralized repository for external data 108 may be aseparate database from consolidated database 112. Centralized repositoryfor external data 108 may also be a table or other data storagestructure or file within consolidated database 112, wherein those tablesor other data storage structures or files are set aside as repositoriesfor data obtained from external database(s) 106. The centralizedrepository for external data 108 may take other forms, including but notlimited to a large storage cache within the random access memory orother memory within computer or server 102. The exact details of thisarchitecture are not essential to the operations of this invention.

IV. Process

FIG. 2A is a flowchart illustrating a customer linking andidentification capability (CLIC) method 200 according to one embodimentof the present invention.

The method begins with step 202, wherein the method collects internalcustomer account data. As previously indicated, this data can representa wide variety of accounts from multiple business units within abusiness such as a financial institution. These accounts can be bankingaccounts, savings accounts, credit card accounts, investment accounts,mortgage accounts, and other such accounts. In one embodiment of theinvention, the collected internal customer account data is stored inconsolidated database 112.

Consolidated database 112 may take the form of a table or system oftables on a single database server or even on a single disk. However,with current capabilities in distributed processing and distributedtechnologies, a consolidated database can actually be a system ofdistributed databases spread over several servers, or possibly even overseveral networks, provided that the software that is used to manage theconsolidated database 112 is capable of treating the physicallydistributed database as one logically consolidated database forprocessing purposes.

In step 204, databases are searched for personal identification (PID)information, and in one embodiment the search is for PID to be found inexternal database(s) 106. In step 208, method 200 analyzes the internalcustomer account data and also analyzes the external PID to create alinkage between customer accounts. The details of all these steps arediscussed further below. In step 209 the entire process may bereinitiated by returning to step 202 based on a variety of criteria ortrigger events including, for example and without limitation, on ascheduled basis, on an on-demand basis, that is, when the process isinitiated by a database manager or other staff member of the business,or as it is determined that one or more business units have collectednew customer account information.

FIG. 2B is a flowchart illustrating a CLIC process according to anenhanced version 201 of the embodiment of the invention illustrated inFIG. 2A, showing additional steps which may be advantageous to perform.

As before, step 202 represents collecting internal customer accountdata, wherein the internal customer account data is collected intoconsolidated database 112. In step 204 there is again a search for PIDinformation, wherein the search for PID information is conducted bysearching external database(s) 106.

In one embodiment of the present invention step 206 entailsconsolidating the external PID into a centralized repository forexternal data 108. This consolidation of the external PID intocentralized repository 108, while not essential to the presentinvention, may facilitate effective processing of the external PID data106 which is being used to analyze internal customer account data 104.

In an alternative embodiment of the present invention, rather thanconsolidating external PID information 106 into a centralized repositoryfor external data 108, external PID data 106 may he evaluateddynamically as it is accessed to determine if it is a potentialcandidate match to internal customer account data 104. This process ofdynamic, real-time evaluation, wherein some of the external PID data 106is temporarily retained for further immediate processing, is known as“netting down.” External PID data 106 which is determined, via thenetting down process, to be a potential match to internal customeraccount data 104 is retained in temporary storage, such as RAM or someother short-term database, and then may he immediately compared in moredetail to internal customer account data 104 as described in thefollowing steps. This detailed comparison may occur in parallel with anongoing search of other sources of external PID data 106 for potentialcandidate matches.

The method, system, and computer program product for linking customerinformation will be described in the remainder of this document as usingthe centralized repository for external data 108 as a means for storingexternal PID data, but this is for purposes of illustration only;persons skilled in the relevant art(s) will appreciate that the method,system, and computer program product of the present invention mayequally well be implemented utilizing the netting down process asdescribed here, i.e., a process of dynamically accessing and evaluatingexternal PID data 106 in real-time, immediately prior to and/or inparallel with comparing that data in further detail against internalcustomer account data 104.

Step 208, as before, entails the analysis of the internal customeraccount data 104 and the external PID 106 to create a linkage betweencustomer accounts. Step 210 entails performing manual linkages ordelinkages. Manual linkages or delinkages typically arise when customerscall in and, in the course of conversations with customer servicerepresentatives, provide information which indicates that some of theiraccounts which have previously been separate should be linked together;or, on the other hand, when the customers call in and indicate a problemwhich indicates that two accounts which are linked to that customershould not both be linked to that customer. In this case, the customerservice representative, using a standard interface (not shown), is ableto manually link or delink accounts from the customer.

Step 211 entails storing the revised customer and account linkages. Step212 entails a further analysis and validation of the revised account andcustomer identification linkages. This further analysis and validationcan be performed manually by a designated database manager whose job isto maintain the integrity of the CLIC database 112. There may also beautomated systems which can perform a review and screening of the datato identify errors.

Step 214 entails correcting erroneous linkages. Step 216 entailsmodifying the rules used to analyze the consolidated database 112. Therules are modified based on the identified errors and corrections thatare made, such that the same types of errors or similar types of errorswill not occur again.

The entire process may be repeated starting with step 202 based on avariety of criteria or trigger events, including for example and withoutlimitation on a scheduled basis, on an on-demand basis, that is, whenthe process is initiated by a database manager or other staff member ofthe business, or as it is determined that one or more business unitshave collected new customer account information.

FIG. 3 provides an example of the flow of information which is involvedin implementing step 202 of the CLIC method. Step 202 entails collectinginternal customer account data into a consolidated database 112. Asillustrated in FIG. 3 there can be a variety of sources of internalcustomer data.

The example data shown here includes a variety of sources of data whichwould be used by one example financial institution, the American ExpressCompany. The Legacy 302 and Triumph 304 databases hold accountsreceivable data for various types of consumer, small business, andlarger business credit cards (CCSG, OSBN, and CORP, respectively). Theseare all consolidated into a global new accounts table (GNAT) database306. Databases for other customer relationships 308 include membershipbanking (MSB), investment account relationships (INVST), portfoliosacquired from other banks (TSYS), consumer and business loan accounts(MET), consumer travel network transactions (CTN), and equipment leasingaccounts (LEA). There are also databases for consumer and small businessapplications for new accounts 310 (GNA and Picasso, respectively).Finally, there is manual data entry by financial institutionrepresentatives 312.

The sample sources of data shown are purely for purposes ofillustration, and it would be clear to one skilled in the relevantart(s) that other organizations, businesses, and business units wouldhave their own, business-appropriate or organization-appropriate sourcesof customer and account data. Together these sources comprise theinternal customer account data 104.

In step 202, all of the internal customer account data 104 is taken inand processed via an extractor and filter 314. The extractor and filter314 has a set of rules or criteria which selects and extracts the PIDinformation that may be used for establishing customer and accountlinkages, while screening out (i.e., filtering out) any data which isnot necessary for creating those linkages. The filtered data, withpertinent account owner information, is then stored in the CLIC database112.

In one embodiment of the present invention, for example, transactiondata would not be necessary. In other words, data regarding specificsales, specific purchases, and related transaction data would not benecessary for establishing linkages between customers and accounts.Similarly, any data regarding customer preferences, e.g., preferences asto marketing campaigns they wish to receive, or how they wish theirprivacy to be handled, would also not be pertinent to the current methodand would be filtered out by extractor and filter 314.

As another example of the filtering process, persons who may beassociated with an account but are not owners of the account would alsobe filtered out via extractor and filter 314. For example, in a creditcard account, there may be several people known as “authorized agents”or “authorized managers”, who have the right to use the credit card butare not account owners. Extractor and filter 314 would screen outauthorized agents or authorized managers. In an alternative embodimentof the present invention, those persons who are filtered out, e.g., theauthorized agents or authorized managers, may be assigned their ownunique persistent ID which would be stored in the CLIC database, andwhich would then be available for later processing if other accountsbecome associated with those persons.

FIG. 4 provides an example 400 of the method by which extractor andfilter 314 extracts data from internal customer account data 104 andplaces the data in CLIC database 112. In the example shown, the sourceof data is the GNA database 306. Among the data stored in the GNAdatabase 306 is an account 402 for a Basic Gold Rewards card account fora customer 404 John B. Doe. Included in the account data is a list ofpurchase activity 406. When the data is filtered through extractor andfilter 314, the account information 402 survives the filtering processand is stored in the CLIC database 112 along with the customerinformation 404 for John B. Doe. However, the transaction history orpurchase history 406 has been removed during the filtering process.

FIG. 5A shows a combined process 500 which embodies both step 204 ofmethod 201, wherein external data 106 is searched and filtered; and step206 of method 201, wherein the filtered external data is consolidatedinto the centralized repository for external data 108. As shown in FIG.5A, there are a variety of possible sources 106 for external personalidentification (PID) information. These sources 106 include US PostalService change of address data 502, credit history collected prior toFCRA and GLBA 504, marketing, demographic, and survey data files 506,sources of credit data 508, other United States Postal Service data 510,phone directories 511, and public and court record files 512. It will beappreciated by those skilled in the relevant art(s) that the sources ofdata illustrated in FIG. 5A and described here are representative only,and that in fact there exist thousands if not more potential sources 106of PID information. The search of any and all of those sources fallwithin the scope of the current invention, which is neither limited tonor specifically defined by the sources described above by way ofillustration.

These external database(s) 106 which constitute the possible sources ofPID are searched for PID information at step 204, wherein only some ofthe available data is actually selected through a matching and filteringprocess 514, before being consolidated in step 206 into the centralizedrepository for external data 108. As shown in FIG. 5A, matching andfiltering process 514 relies on data from CLIC database 112 to performits matching and filtering functions. Specifically, the matching andfiltering process 514 only collects PID information which is reasonablylikely to be related to information on customers in the CLIC database112. PID information which is not likely to be related to customers inthe CLIC database 112 is filtered out during the matching and filteringprocess 514.

FIG. 5B provides a detailed representation of external database searchprocess 204, associated matching and filtering process 514, andconsolidation step 206. Step 204 entails searching external database(s)106 for PID using a variety of search criteria. In one embodiment of thepresent invention, these criteria include searching external database(s)106 based on the names of individuals in the CLIC database 112, or basedon the addresses of individuals in the CLIC database 112, or based onthe social security numbers (SSN's) of individuals in the CLIC database112, or based on the phone numbers of individuals in the CLIC database112, or doing a search based on a combination of two or more of theabove criteria. As can be appreciated by persons skilled in the relevantart(s), other types or categories of PID data can also be used as thebasis for searching external database(s) 106.

In one embodiment of the present method, searches based on some types orcategories of PID data are always executed, while other searches wouldonly be performed conditionally. Searching by name, address, or phonenumber may always be performed, while searches by SSN would not alwaysbe executed. For example, if an account belongs to an individual or to abusiness which is a sole proprietorship, then a search including SSNwould be performed. On the other hand, if an account is associated witha business which is not a sole proprietorship, then the impact of theSSN in the search process is reduced or may not be relevant at all(since the SSN of the account owner may not be available).

In an alternative embodiment of the present invention, searches on allavailable categories of PID information or a selected subset ofcategories of PID information are always performed. In anotheralternative embodiment of the present invention, searches on allavailable categories of PID information or a selected subset ofcategories of PID information are always conditional, based on variouscriteria regarding the status of the account information in CLICdatabase 112.

Matching and filtering process 514 employs a set of matching rulesand/or matching criteria to determine which PID information in externaldatabase(s) 106 will be considered a potential match to PID informationin consolidated database 112. FIG. 5B provides sample matching criteria.For example, in the case of a search based on name matching, externalPID information is considered to be a match if certain variations on aname in CLIC database 112 are found. Also collected during this matchingand filtering process, for any customer name in consolidated database112, are all of the following which may be found in external database(s)106: addresses associated with the name, addresses associated withvariations on the name, SSN's associated with the name, SSN's associatedwith variations on the name, phone numbers associated with the name,phone numbers associated with variations on the name, dates of birth(DOB's) associated with the name, DOB's associated with variations onthe name, generation codes (Jr., Sr., etc.) associated with the name,and generation codes associated with variations on the name.

FIG. 5B similarly illustrates matching criteria associated with a searchon addresses, SSN's, and phone numbers. In each case, search process 204and matching and filtering process 514 search both for exact matcheswith, and for variations on, the addresses, SSN's, and phone numbersstored in CLIC database 112. In addition, for each such match found,i.e., both for direct matches and for matches based on variations,search process 204 and matching and filtering process 514 collectrelated, pertinent external PID data associated with the external match.

For example, suppose a customer in CLIC database 112 has an address of“190 N. Main Ave., Tucson, Ariz. 85701”, with “Avenue” abbreviated as“Ave.”. Suppose also that during a search of an external database, avariation on the address is found, namely “190 N. Main Avenue, Tucson,Ariz. 85701”. Matching and filtering process 514 will consider these twoaddresses to be a match; guided by matching and filtering process 514,search process 204 will not only collect the matching external addressdata (namely, “190 N. Main Avenue, Tucson, Ariz. 85701”), it will alsocollect all externally identified names associated with “190 N. MainAvenue, Tucson, Ariz. 85701”, all SSN's associated with “190 N. MainAvenue, Tucson, Ariz. 85701”, all valid SSN variations associated with“190 N. Main Avenue, Tucson, Ariz. 85701”, all phone numbers associatedwith “190 N. Main Avenue, Tucson, Ariz. 85701”, all DOB's associatedwith “190 N. Main Avenue, Tucson, Ariz. 85701”, and all generation codesassociated with “190 N. Main Avenue, Tucson, Ariz. 85701”.

As another example, suppose a customer in CLIC database 112 has an SSNof 123-45-6789, with the dashes included as shown. Suppose also thatduring a search of an external database, a variation on the SSN isfound, namely “123456789” (without the dashes). Matching and filteringprocess 514 will consider these two SSN's to be a match; guided bymatching and filtering process 514, search process 204 will not onlycollect the matching external SSN (namely, “123456789”), it will alsocollect all externally identified names associated with SSN “123456789”,all other valid SSN variations associated with SSN “123456789”, alladdresses associated with SSN “123456789”, all phone numbers associatedwith SSN “123456789”, all DOB's associated with SSN “123456789”, and allgeneration codes associated with SSN “123456789”.

Various embodiments of the present invention may employ different rulesor algorithms to determine what are valid and non-valid variations on aname, an SSN, a DOB, or other PID information. One embodiment may employrules which indicate that names, SSN's, DOB's, and similar informationwith the same essential content, but different formats, are consideredto be matches. In another embodiment, the rules may indicate thatcertain items of omitted information, such as a missing middle name ormiddle initial in a name, or a missing day of the month in a DOB,constitute valid variations. Other embodiments may specifically disallowone or both of these variations.

Those skilled in the relevant art(s) will appreciate that the filteringaspect of matching and filtering process 514 is at least partly implicitin the matching process. In other words, external PID information whichfails to match with internal PID information in the consolidateddatabase, based on the matching criteria of the present invention, willnot be selected for analysis or importation in method 200 or method 201,and therefore such non-matching PID data is inherently filtered.

Similarly, it will be appreciated that active filtering criteria couldbe included as well as part of matching and filtering process 514. Toname just one example, the date of external PID information could beused as a filter criteria. For one possible embodiment of the presentinvention, if it is possible to determine the date of external PIDinformation, a filter criteria may determine that certain types ofexternal PID information which are indicated as being older than somefilter date will not be included.

More generally, persons skilled in the relevant art(s) will appreciatethat the matching and filtering criteria shown in FIG. 5B and describedabove are for purposes of illustration only, representing only anembodiment of the invention, and that a wide variety of suitablematching and filtering criteria may be employed to implement the presentinvention.

Finally, in step 206 the external PID information collected fromexternal database(s) 106 via search 204 and matching and filteringprocess 514 is consolidated into a centralized repository for externaldata 108.

FIG. 6 provides a concrete illustration 600 of steps or processes 204,206, and 514, where sample external data 106 is searched, and where thedata is filtered and consolidated into the centralized repository forexternal data 108. Sample external database 106A contains at least twosets of sample external data, namely sample external data 602 related toa person variously known as John B. Doe, JB Does, or John Doe, andsample external data 604 related to a person variously known as J. Smithor Jim Smith. Sample external database 106 a is searched in step 204,and the searched information is passed through matching and filteringprocess 514.

Matching and filtering process 514 does the filtering based on PID data404 found in CLIC database 112. In this case, the PID information 404relates to John B. Doe. Therefore, information pertaining to John B.Doe, i.e., names, addresses, SSN information, and phone numbers, all ofwhich could be related to John B. Doe, are passed by matching andfiltering process 514, and then during step 206 are consolidated intothe example centralized repository for sample external data 108A. Twoparticular items of data which have been extracted from the externaldatabase(s) 106 and consolidated into the centralized repository are adata record 606 pertaining to a consumer JB Doe and a data record 608pertaining to a business owned by a JB Doe.

Once external data has been filtered and consolidated into thecentralized repository for external data 108, the next stage in method200 or method 201 is step 208, which entails analyzing the internalcustomer account data in the CLIC database 112 and the external PIDinformation now stored in the centralized repository for external data106 in order to create a linkage between customer accounts.

FIG. 7 shows a series of steps 700 which are used to implement step 208of method 200 or method 201. In step 702, the external data in thecentralized repository for external data 106 and the internal customerdata in the CLIC database 112 are analyzed according to an initial setof rules. Based on the analysis in step 702, the present method makes aninitial linkage recommendation 704. The next step 708 analyzes theinitial linkage recommendation according to a secondary set of rules.Based on this analysis, a secondary linkage recommendation is made instep 710. Finally, based on the secondary linkage recommendation,customer accounts are linked to unique customers in step 712.

It should be noted that there is nothing inherent in the overall methodof the present invention which requires that the process of linkingcustomer accounts must occur in two stages, or that the rules whichdetermine the linking process comprise an initial set of rules and asecondary set of rules. In another embodiment in the present invention,there is only a, single set of linking rules and a single stage oflinking recommendations. In yet another embodiment of the presentinvention, there are three or more sets of linking rules, and three ormore stages of linking recommendations.

For those embodiments of the present invention which contain two or moresets of linking rules, and two or more corresponding stages of linkingrecommendations, there are several objectives. One objective of havingmultiple sets of linking rules is that a first stage of the linkingprocess can be accomplished via third-party or standardized oroff-the-shelf software which employ generic or commonly used datalinking rules or data linking algorithms, while a second stage or secondand later stages of the linking process can employ data linking rules ordata linking algorithms which are customized to the needs of aparticular business or organization. Another objective of havingmultiple sets of linking rules, with two or more corresponding stages oflinking recommendations, is that manual or automated validationprocesses can be introduced at multiple points in the linking process,prior to a final set of account and customer links being implemented.

FIG. 8 shows a series of steps 800 by which step 702, the analysis ofexternal data and customer data according to an initial set of rules, isimplemented. In steps 800, data is taken from the consolidated database112, and also taken from the centralized repository for external data108, and a series of rules are used to try to establish matches. Forexample, the rules may include rules 802 based on name matches, rules804 based on address matches, rules 806 based on SSN matches, rules 808based on phone number matches, and rules 810 based on match rankings anddata sources. There may be other rules 812 as well.

The rules 810 based on reliability, recency, and corroboration of datasources and data types pertain to assessments and rankings to determinewhich type of matches are more likely to result in a reliable matching.For example, a match ranking may indicate that minor variations on namesare highly likely to be good matches for each other. An example of aminor variation in a name is a case where one name (such as one found inthe CLIC database 112) has a middle initial, whereas another name (suchas one found in the centralized repository for external data 108) isidentical to the name in the CLIC database 112 except for the lack ofthe middle initial. In another example, a match ranking may indicatethat a match based on an SSN match, where two numbers are transposedbetween two different SSN's, has a lower likelihood of being a correctmatch.

A person skilled in the relevant aft(s) can appreciate that various setsof rules can be implemented to determine the likelihood that varioussources of PID information are reliable, or that various different PIDmatching rules are reliable. Persons skilled in the relevant art(s) willalso recognize that algorithms can further be implemented, based onvarious matching rules, to determine that two PID's, which initiallyappear to be related to two different people, are in fact actually thesame PID of one unique person.

Based then on these initial rules, which may comprise rules regardingname matches, address matches, SSN matches, phone matches, rules basedon match rate rankings and data sources, and still other rules, aninitial set of linking recommendations are arrived at in step 704.

FIGS. 9A and 9B together show an example 900 of step 702, wherein twoexisting internal PID's in the CLIC database 112 can be matched up witha searched for and saved PID in the centralized repository for externaldata 108; the result is a recommendation 704 for a new link betweencustomer accounts. Referring back to FIG. 4, a new account 402 for aBasic Gold Rewards Card, which is associated with customer John B. Doe404, is stored in the CLIC database 112. Not shown in FIG. 4, butassumed for purposes of this example and shown in FIG. 9A and FIG. 9B,is that a customer JB Doe 912 with a Basic Blue Card account 910 is alsostored in the CLIC database 112. Customer John B. Doe 404 has a homeaddress, while customer JB Doe 912 has a business address.

Referring back to FIG. 6, an external PID for an individual JB Doe 606is imported into the centralized repository for external data 108 a.Also referring back to FIG. 6, an external PID for a business owner JBDoe 608 is imported into the centralized repository for external data108 a.

Now returning to FIG. 9 and example 900, the method of step 702,involving linking rules, is exemplified. The initial linking rulesassociate John B. Doe 404 and JB Doe 606 based on a high probabilitypartial name match and an exact address match. The initial linking rulesassociate JB Doe 606 and JB Doe 914 based on an exact name match, a cityand state match, and a work phone match. Finally, the initial linkingrules also associate JB Doe 912 and JB Doe 914 based on an exact namematch and an exact business address match.

Through this series of links, namely John B. Doe 404→JB Doe 606,followed by JB Doe 606→JB Doe 914, and then JB Doe 914→JB Doe 912, wearrived at the linkage John B. Doe 404=JB Doe 912. Based on the set ofrules, then, two separate customers 404 and 912, with two separateaccounts 402 and 910 respectively, can now be linked to each other. FIG.9B shows this initial linking recommendation 704 a.

There are many variations in the analysis via a set of initial rules 702that can be used for making the initial linkage recommendation 704. Forexample, the analysis via a set of initial rules 702 will create apreliminary, plausible set of linkages 704 between different customersand customer accounts. The purpose of analyzing the initial linkagerecommendations 704 according to a secondary set of rules 708 is to geta more refined and more accurate linking recommendation 708 ofcustomers, both removing some linkages that should not have been made inthe first place, and detecting some linkages that might have beenomitted by the preliminary linkage rules employed in step 702.

FIGS. 10A and 10B provide illustrations 1000 and 1010, both of analysesvia secondary linking rules 708 and of the linkage recommendations 710that can result from the analysis via secondary rules 708.

FIG. 10A shows two customers, George F. Doe 1002 and George F. Doe 1004,where an initial recommendation did not link the two customers becauseof a low reliability associating the consumer name with the businessaddress, since George F. Doe 1002 is listed with a home address, andGeorge F. Doe 1004 is listed with a business address. However, thesample secondary linkage rule 708A states that if there is an exactmatch on the full name and the social security number, and if there isno generation code conflict, then a secondary linkage recommendationshould be made. A secondary linkage recommendation 710A is illustratedwherein a persistent ID has been assigned jointly to both George F. Doe1002 and George F. Doe 1004.

FIG. 10B illustrates the case where Stanley C. Doe 1012 and Stanley C.Doe 1014 were initially not linked because the social security numberwas missing on the Gold Card of Stanley C. Doe 1014. However, secondarysample linkage rule 708B states that a link should be made if there isan exact match on the full name and address, and there is no generationcode or SSN conflict, wherein a blank SSN is considered to be synonymouswith there being no conflict. As a result, a secondary linkagerecommendation 710B is made between Stanley C. Doe 1012 and Stanley C.Doe 1014, both of whom have the same name and the same address and arethen jointly assigned the same persistent ID.

The process described above, wherein two customers formerly viewed asseparate customers are discovered to actually be the same person, can berepeated as many times and as often as necessary. The end result may be,and in a large enough database is likely to be, that at least in somecases more than two customers will ultimately be identified as actuallybeing the same person. That is to say, through this process, multiplecustomer records which were viewed as records of distinct persons willbe linked as being one unique person.

In addition, a thorough and exhaustive processing of a CLIC database 112according to the present method and invention is likely to result in theremoval of most if not all of the redundant customer identifications.Put another way, the present method, when employed exhaustively, mayresult in the identification of multiple sets of customers, wherein thecustomers in each set become recognized as actually being the sameperson, and are so identified through this process. in addition, all theaccounts associated with the customers in each such set will now belinked to each other, and to the one unique customer of the set, throughthis process.

In any database system, an issue arises when attempting to consolidate,join, or otherwise associate data records or other data structures whichwere previously viewed as separate, namely, the question of preciselyhow to modify the existing data in order to reflect the newassociations. This is particularly a significant issue in the context ofthe present invention, and especially in contexts where the method ofthe present invention is to be implemented in a large organization. Eventhough, in step 202 of methods 200 or 201, all internal customer accountdata is consolidated in the CLIC database 112, it may also remain thecase that separate databases and entire separate data processing systemsremain in use in different business units of the large organization.

FIGS. 11A and 11B illustrate a method according to one embodiment of thepresent invention for linking customer accounts, and for consolidatingcustomer information, which addresses this challenge, i.e., whichimplements the actual linking process which is described in steps 704,710, and 712 of step 208.

FIG. 11A shows how a linkage recommendation 704 or linkagerecommendation 710 is made. The first step 1102 entails identifying aset of customers as being a single unique customer. This means that aset of customers, i.e., internal customers, who were initially regardedas being distinct or separate customers, are now recognized as all infact being the same unique customer according to the methods describedabove. In step 1104, it is recommended that all the customers in the setbe consolidated into a single unique customer, and in step 1108, it isrecommended that all customer accounts associated with the customers inthe set be linked with the single unique customer.

FIG. 11B shows the actual steps 712 involved in making these linkagesaccording to one embodiment of the present invention. Step 1112 entailsaccepting the recommendation that identifies a set of customers as beinga single unique customer. In step 1114, there is assigned to allcustomers in the set a unique persistent ID. This unique persistent IDis one single, unique signifier completely unique to this newlyidentified unique customer, which serves to distinguish this customerfrom all other customers throughout the consolidated database 112, andfurther to distinguish this customer from all other customers withcustomer information stored on any other databases throughout thebusiness, organization, or other enterprise. Finally, in step 1116, themethod assigns to each customer account which belongs to that customerthe persistent ID of the unique customer.

The persistent ID may take the form of a number, which may be expressedin base ten, in hexadecimal, in octal numbering, in binary, or in someother numbering system. In an alternative embodiment the persistent IDmay take the form of a code which is alphanumeric, or which strictlyuses alphabetic characters, wherein the characters of the alphabet maybe selected from the American alphabet, or from the alphabet of anyknown language, or any language to be developed in the future. In analternative embodiment of the invention, the persistent ID may take someother representational form, such as a bar code, a graphic imageincluding for example and without limitation a vector graphic image or abitmapped graphic image, an audio representation, a videorepresentation, a holographic representation or encoding, or any otherform which can be used to uniquely identify a record or identify data inany kind of storage medium wherein customer information and customeraccount information may be stored in a database of any kind.

An advantage of this method, wherein a unique persistent ID is assignedto each unique customer, is that it remains possible to retain separatecustomer databases, and possibly even different customer descriptions,on multiple databases throughout the business enterprise. Thus, whilethe CLIC database 112 is used to store all internal customer IDs forpurposes of implementing the current invention, the unique, persistentcustomer IDs, once generated, can be distributed among other databaseswhich retain customer records.

In one example, if a customer identified as JB Doe on one database andJohn B. Doe on another database is in fact the same unique customer,then the assignment of a singular, unique persistent ID to both JB Doeand John B. Doe ensures that the associated data records will berecognized throughout the business as belonging to the same customer.With this approach, it may be desirable to implement methods whereinwhen updates are made to a data record for a customer anywhere in thebusiness, suitable updates are also made to other data records for thesame customer, stored on other databases throughout the business.

It will be appreciated by those who are skilled in the relevant art(s)that the method just described is amenable to numerous variations interms of the steps of processing or stages of processing involved, andin terms of the particular configuration or particular architecture ofthe system. For example, the method just described could entailpermitting multiple records of the same customer to remain on multipledatabases, as long as all such records are linked by the same uniquepersistent ID. However, in another embodiment of the present invention,all records identifying a unique customer could be consolidated into asingle database which is then referenced, throughout the enterprise,anytime customer information is required. This single database could besame database as the CLIC database 112. In another embodiment, the CLICdatabase could be used for implementing the method of the currentinvention, while a second database which mirrors the CLIC database 112,and in particular stores all the unique customer information andcustomer IDs, could be used for all other business-related processing.

Similarly, while the method of the present invention generally envisionsusing a large number of external database(s) as a means of obtainingvariations on a customer identification for purposes of matchingcustomers PID's, it is possible that a similar matching process couldalso entail simply using different sources of internal personalidentification without reference to any external database(s). Ingeneral, it is an objective of the present invention to recognize thatcertain internal PID's which heretofore have been interpreted asseparate customers are in fact one and the same customer, and havingmade that recognition to ensure that all accounts which are associatedwith those PID's become associated with the single unique person who isactually the unique customer behind all those different personalidentifications.

FIG. 12 illustrates a method 1200 according to an embodiment of thepresent invention which results in linking disparate personalidentifications and accounts that should appropriately be linked to eachother. Step 1202 entails reading a PID information for a customer who isan owner of a first account, which may be a banking account, aninvestment account, or any number of other kinds of institutionalaccounts. Step 1204 entails reading a PID information for a secondcustomer who is an owner of a second account. Step 1206 entailssearching for PID information which is related to the PID information ofthe first customer, or searching for PID information which is related tothe PID information of the second customer, or possibly searching forPID information which is related to the PID information of both thefirst customer and the second customer.

Step 1208 entails analyzing all of the previously gathered PIDinformation relating to the first customer, the second customer, and anyPID information related to either or both of the first customer and thesecond customer, to determine if the first customer is the same uniquecustomer as the second customer.

It will be appreciated by those skilled in the relevant art(s) that themethod for this analysis of step 1208 will be similar to thosepreviously described, using linking rules so as to determine matchesbetween names or similarities between names, matches between socialsecurity numbers or similarities between social security numbers,matches between addresses or similarities between addresses, recordsindicating change of address, records indicating change of name, matchesbetween telephone numbers or similarities between telephone numbers, andother recognitions of either matches or similarities between PID data,and/or transitions of PID data such as change of address, change ofname, change of phone number, and related changes. The list of linkingcriteria presented is representative only, and the actual linkinganalysis need not include all of these rules or criteria, and mayinclude others not listed here, including rules of a probabilisticnature wherein an evaluation is made of the likelihood that certainmatches are reliable or not reliable.

Having performed this analysis 1208, the method then determines in step1210 whether the first customer is in fact the same person as the secondcustomer. If the answer is yes, then the first customer is linked to thesecond customer account, meaning it is recognized that both accountsactually belong to the same customer.

Optional step 1214 would entail consolidating the first customer PIDinformation and the second customer PID information into oneconsolidated customer record. If the first customer is not the same asthe second customer, then step 1216 either entails stopping the processor optionally repeating the process, with either one or two new customerrecords associated with customer accounts.

On the other hand, if the first customer and the second customer arerecognized as being the same customer in step 1210, then followingeither step 1212 or step 1214, step 1216 is again performed, meaningeither that the process stops, or optionally is repeated with anevaluation of the same customer against other customer records, or withan evaluation of two new customer records.

Finally, those experienced in the art will recognize that there are anumber of variations on the indicated methods of the current inventionwhich fall within the essential spirit and scope of the invention. Forexample, as has been indicated here, linking customers and linkingcustomer accounts is done by assigning to each customer a uniquepersistent ID, which indicates that previously separate customers are infact the same customer; and further, that the unique persistent ID isthen assigned to all accounts that are associated with the uniquecustomer.

However, persons skilled in the relevant art(s) will recognize thatthere are numerous other methods for linking both customers and customeraccounts. For example, customers who are construed to be the samecustomer, but still retain a separate ID number, could nonetheless havea field in their data records which acts as a pointer or cross referenceto other ID numbers which have been linked to the same customer. Similarpointer-type structures could be used to link accounts to all thesecustomers who are now recognized as being in fact the same uniqueperson.

In yet another possible embodiment, a database table or similar databasestructure could be used to list the names of all customers who are nowrecognized as being one unique customer, along with the accounts whichare recognized as being associated with that one unique customer. Otherpossible means of identifying the disparate personal identificationsbelonging to disparate customers as actually being one unique customer,and also recognizing that the accounts associated with those disparatecustomers are actually linked to one unique customer, can also beenvisioned and implemented.

The final stages of method 201 entail link validation 212, linkcorrection 214, and modification 216 of the linking rules based ondiscovered errors.

FIG. 13 provides an illustration 1300 of two examples of step 212 of thepresent method, wherein linkage errors are identified, and also of step214 of the present method, wherein the linkage errors are corrected. Inexample 212 a there is an overlink error indicating accounts which werelinked via common persistent ID value ‘1’, but which should not havebeen linked. In this instance, persons with very similar names “JohnBrown Doe” and “Jonah Braun Doe” are both living at the same address.Even though their SSN's are different, they were linked on the basis ofthe address and the similarity of the names.

In example 212 b we have an underlink error, wherein accounts whichshould have been linked were not, and so have separate persistent IDvalues ‘3’ and ‘4’. In this case, the first account has the name “Bob C.Doe, Jr.” with proper spacing among all the elements of the name,whereas the second name has “Bob C. Doeir,”, where there is an omissionof a space between the last name “Doe” and the generation code “Jr.”. Asa result, the last name appears to be “DoeJr.”. In addition, since thestreet addresses are different, this is a further signal to the methodthat this is not the same person. (In one case an actual street addressis used, while in the other case there is a P.O. box.) Even though thecity and state are the same, and even though the SSN, DOB, and even thephone numbers are the same, nonetheless the discrepancy in the names andstreet addresses results in the two accounts not being linked to eachother.

In step 214 a manual or automated linkage correction is made. A manuallinkage correction would involve a financial institution databasemanager or financial institution customer service representativediscovering the failure of the two accounts to be linked, or discoveringtwo accounts being linked which should not have been linked, andmanually separating them.

An automated linkage correction is accomplished by a set of rules oralgorithms which do a final pass and search for any kind of subtleerrors which were not previously flagged. For example, using theunderlink error 212 b described above, a software algorithm could bedesigned to go through and compare names for the possibility that twonames which are similar, but not the same, are actually the same name.Persons skilled in the relevant art(s) will recognize that algorithmscan be employed here similar to those employed in spell checkingsystems, where the software can experiment with transposing letters in aname, or introducing spaces or removing spaces, as a way of generatingalternative names and comparing those alternative names to see if thereis a match on that basis.

A combination of automated and manual linkage correction could beemployed. For example, the software could generate variations on names,addresses, SSN's, and other PID data, and/or suggest possible linkagesbased on those variations; however, the final determination as to whichaccounts to link or to not link could be made by a human operator, whowould be presented with these linkage options via a computer interface(not shown).

As a result of the linkage corrections shown in illustration 1300, thecorrected customer account 214 a for John Brown Doe is shown withpersistent ID ‘1’, while the corrected customer account 214 b forseparate customer Jonah Braun Doe is shown with different persistent ID‘2’. Further, the corrected customer accounts 214 c and 214 d forcustomer Bob C. Doe, Jr. now share the same persistent ID ‘3’,indicating that both accounts belong to the same unique customer.

In one embodiment of the present invention, the current method may takethe additional step of making any necessary corrections to customerdata, based on the analyses described above. In this case, the erroneouslisting in example 212 b for ‘Bob C DoeJr’ has been corrected for theaccount 214 d, which now reads ‘Bob C Doe Jr.’

In one embodiment of the present invention, a hierarchy exists among thelinkage rules and linkage recommendations of method 200 or method 201.FIG. 14 is a block diagram indicating one possible hierarchy. Linkagerules or recommendations for linkages of higher priority will takeprecedence over those of lower priority. For example, there is a set ofinitial rules 702 which leads to the initial linking recommendation 704,both of which have the lowest priority 1402. That is followed by thesecondary rules 708 and secondary linking recommendations 710 which havea higher priority 1404. The higher priority means that those secondaryrules 708 and secondary linking recommendations 710 may override theinitial linking rules 702 and initial linking recommendations 704,resulting in the customer ID and account linkages 712.

The highest priority 1408 is given to the manual overrides, which trumpboth the initial rules 702 and secondary rules 708, resulting in revisedcustomer ID and product linkages 211. In another embodiment of thepresent invention there may exist a more fine-grained hierarchy of rulesand linking recommendations than shown in the embodiment discussed andillustrated here. In another embodiment of the present invention, thereis no hierarchy among the linking rules or recommendations.

V. Example Implementations

The present invention, as typically embodied in a system 100 oforganizational intranet 114 and external network 110 and externaldatabase(s) 106, and as embodied in method 200 or method 201, or asimplemented in alternate embodiments as suggested throughout thisdetailed section and the appended claims, or any part(s) or function(s)thereof, may be implemented using hardware, software, and human operatordecision making, or a combination thereof and may be implemented in partor in whole by one or more computer systems or other processing systems.However, the manipulations performed by the present invention were oftenreferred to in terms, such as analyzing or comparing, which are commonlyassociated with mental operations performed by a human operator.

While, as indicated above, the intervention of a human operator may playa role in validity checking of auditing of, or modification of thecustomer and account linkages established in the present invention, suchintervention of a human operator is only necessary in some embodimentsof the present invention and not others. In most cases, most andpossibly all of the operations described herein which form part of thepresent invention are performed without the intervention of a humanoperator. Rather, the operations are machine operations. Useful machinesfor performing the operation of the present invention include generalpurpose digital computers or similar devices.

In one embodiment, the invention is directed toward one or more computersystems capable of carrying out the functionality described herein. Anexample of a computer system 1500 is shown in FIG. 15.

The computer system 1500 includes one or more processors, such asprocessor 1504. The processor 1504 is connected to a communicationinfrastructure 1506 (e.g., communications bus, cross-over bar, ornetwork). Various software embodiments are described in terms of thisexemplary computer system. After reading this description, it willbecome apparent to a person skilled in the relevant art(s) how toimplement the invention using other computer systems and/orarchitectures.

Computer system 1500 can include a display interface 1502 that forwardsgraphics, text, and other data from the communication infrastructure1506 (or from a frame buffer not shown) for display on the display unit1530.

Computer system 1500 also includes a main memory 1508, preferably randomaccess memory (RAM), and may also include a secondary memory 1510. Thesecondary memory 1510 may include, for example, a hard disk drive 1512and/or a removable storage drive 1514, representing a floppy disk drive,a magnetic tape drive, an optical disk drive, etc. The removable storagedrive 1514 reads from and/or writes to a removable storage unit 1518 ina well known manner. Removable storage unit 1518 represents a floppydisk, magnetic tape, optical disk, etc. which is read by and written toby removable storage drive 1514. As will be appreciated, the removablestorage unit 1518 includes a computer usable storage medium havingstored therein computer software and/or data.

In alternative embodiments, secondary memory 1510 may include othersimilar devices for allowing computer programs or other instructions tobe loaded into computer system 1500. Such devices may include, forexample, a removable storage unit 1522 and an interface 1520. Examplesof such may include a program cartridge and cartridge interface (such asthat found in video game devices), a removable memory chip (such as anerasable programmable read only memory (EPROM), or programmable readonly memory (PROM)) and associated socket, and other removable storageunits 1522 and interfaces 1520, which allow software and data to betransferred from the removable storage unit 1522 to computer system1500.

Computer system 1500 may also include a communications interface 1524.Communications interface 1524 allows software and data to be transferredbetween computer system 1500 and external devices. Examples ofcommunications interface 1524 may include a modem, a network interface(such as an Ethernet card), a communications port, a Personal ComputerMemory Card International Association (PCMCIA) slot and card, etc.Software and data transferred via communications interface 1524 are inthe form of signals 1528 which may be electronic, electromagnetic,optical or other signals capable of being received by communicationsinterface 1524. These signals 1528 are provided to communicationsinterface 1524 via a communications path (e.g., channel) 1526. Thischannel 1526 carries signals 1528 and may be implemented using wire orcable, fiber optics, a telephone line, a cellular link, an radiofrequency (RE) link and other communications channels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to media such as removablestorage drive 1514, a hard disk installed in hard disk drive 1512, andsignals 1528. These computer program products provide software tocomputer system 1500. The invention is directed to such computer programproducts.

Computer programs (also referred to as computer control logic) arestored in main memory 1508 and/or secondary memory 1510. Computerprograms may also be received via communications interface 1524. Suchcomputer programs, when executed, enable the computer system 1500 toperform the features of the present invention, as discussed herein. Inparticular, the computer programs, when executed, enable the processor1504 to perform the features of the present invention. Accordingly, suchcomputer programs represent controllers of the computer system 1500.

In an embodiment where the invention is implemented using software, thesoftware may be stored in a computer program product and loaded intocomputer system 1500 using removable storage drive 1514, hard drive 1512or communications interface 1524. The control logic (software), whenexecuted by the processor 1504, causes the processor 1504 to perform thefunctions of the invention as described herein.

In another embodiment, the invention is implemented primarily inhardware using, for example, hardware components such as applicationspecific integrated circuits (ASICs). Implementation of the hardwarestate machine so as to perform the functions described herein will beapparent to persons skilled in the relevant art(s).

In yet another embodiment, the invention is implemented using acombination of both hardware and software.

VI Conclusion

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample, and not limitation. It will be apparent to persons skilled inthe relevant art(s) that various changes in form and detail can be madetherein without departing from the spirit and scope of the presentinvention. Thus, the present invention should not be limited by any ofthe above described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

In addition, it should be understood that the figures and screen shotsillustrated in the attachments, which highlight the functionality andadvantages of the present invention, are presented for example purposesonly. The architecture of the present invention is sufficiently flexibleand configurable, such that it may be utilized (and navigated) in waysother than that shown in the accompanying figures.

Further, the purpose of the foregoing Abstract is to enable the U.S.Patent and Trademark Office and the public generally, and especially thescientists, engineers and practitioners in the art who are not familiarwith patent or legal terms or phraseology, to determine quickly from acursory inspection the nature and essence of the technical disclosure ofthe application. The Abstract is not intended to be limiting as to thescope of the present invention in any way.

1-20. (canceled)
 21. A method of linking data in a computer memorycomprising: a computing system identifying accounts of a first entityand a second entity in an internal database; the computing systemconducting a search of at least one external database to obtain personalidentification information associated with the first entity and thesecond entity; the computing system comparing the accounts of the firstand second entities with the personal identification information anddetermining, based at least in part on the comparing, that the accountof the first entity and the account of the second entity actually belongto a single entity; and where it is determined by the computing systemthat the account of the first entity and the account of the secondentity actually belong to a single entity, the computing system linkingthe account of the first entity with the account of the second entity inthe internal database.
 22. The method of claim 21, wherein the linkingincludes linking the account of the first entity with an identifier thatis associated with the single entity.
 23. The method of claim 21,wherein the conducting the search further comprises: the computingsystem generating a search query based on account data for the accountsof the first and second entities; the computing system sending thesearch query to the external database; and the computing systemreceiving the personal identification information from the externaldatabase in response to the search query.
 24. The method of claim 21,further comprising: the computing system identifying an account of athird entity; the computing system comparing account data for theaccount of the third entity with the personal identificationinformation; the computing system determining that the account of thethird entity actually belongs to the single entity; and the computingsystem associating the account of the third entity with the account ofthe first entity and the account of the second entity in the internaldatabase.
 25. The method of claim 21, wherein the determining is basedon a plurality of linking rules usable to determine when accounts shouldbe linked.
 26. The method of claim 25, wherein the plurality of linkingrules includes a subset of linking rules that are specific to an accounttype that is associated with the accounts.
 27. The method of claim 21,further comprising: the computing system receiving a request to modifyfirst data associated with the account associated with the first entity;and in response to the request, the computing system modifying seconddata associated with the account associated with the second entity. 28.An article of manufacture including a non-transitory, computer-readablemedium having instructions stored thereon that, in response to executionby a computing system, cause the computing system to carry outoperations comprising: identifying accounts of a first entity and asecond entity in a first database; conducting a search of at leastsecond database to obtain personal identification information associatedwith the first entity and the second entity; comparing the accounts ofthe first and second entities with the personal identificationinformation; determining, based at least in part on the comparing, thatthe account of the first entity and the account of the second entityactually belong to a single entity; and associating the account of thefirst entity with the account of the second entity in the firstdatabase.
 29. The article of claim 28, wherein the personalidentification information includes at least one item of informationselected from the group consisting of: a name of the single entity, anaddress of the single entity, a social security number of the singleentity, a date of birth of the single entity, a phone number of thesingle entity, an e-mail address of the single entity, a driver'slicense number of the single entity, or any combination thereof.
 30. Thearticle of claim 28, wherein the associating includes storing anidentifier in association with the account associated with the firstentity.
 31. The article of claim 30, wherein the associating furtherincludes storing the identifier in association with the accountassociated with the second entity.
 32. The article of claim 30, whereinthe identifier is a persistent ID that is unique to the single entity.33. A system comprising: at least one processor; and a memory havinginstructions stored thereon that, in response to execution by the atleast one processor, cause the system to perform operations comprising:identifying accounts of a first entity and a second entity in aninternal database; conducting a search of at least one external databaseto obtain personal identification information associated with the firstentity and the second entity; comparing the accounts of the first andsecond entities with the personal identification information;determining, based at least in part on the comparing, that the firstentity and the second entity are actually a single entity; andassociating the account of the first entity with the account of thesecond entity in the internal database.
 34. The system of claim 33,wherein the first and second entities are individuals.
 35. The system ofclaim 33, wherein the first and second entities are businesses.
 36. Thesystem of claim 33, wherein comparing accounts with the personalidentification information comprises: detecting, based on the personalidentification information and the accounts, first identificationinformation corresponding to the first entity and second identificationinformation corresponding to the second entity; and determining that thefirst identification information matches the second identificationinformation.
 37. The system of claim 33, wherein the at least oneexternal database includes United States Postal Service data, consumercredit data, marketing data, demographic data, survey data, telephonedirectory data, public records data, court records data, or anycombination thereof.
 38. The system of claim 33, wherein the at leastone external database includes law enforcement records.
 39. The systemof claim 33, wherein the operations further comprise: prior to theassociating the account of the first entity with the account of thesecond entity in the internal database, receiving confirmation from anoperator that the account of the first entity and the account of thesecond entity should be associated in the internal database.
 40. Thesystem of claim 33, wherein the operations further comprise: afterassociating the account of the first entity with the account of thesecond entity, in response to a communication from the single entitythat indicates that accounts should not be linked, disassociating theaccounts in the internal database.